I know that the headers expose this as "unavailability", but I think it would look nicer in the docs if it was inverted; e.g. that #[cfg(not(any(target_os = "watchos")))] became #[cfg(any(target_os = "tvos", target_os = "ios", target_os = "macos"))] instead (this is also how Apple's own docs does it).

This interferes with GNUStep of course, but perhaps we can just code in a manual override there for all of AppKit and Foundation for now?

I actually spent a little bit of time doing both variants - all(not(target_os = "ios"), any(taget_os = "macos", target_os = "tvos", target_os = "watchos")). I didn't like it as then everything had a cfg attribute.

Yeah, I agree with that part

#[deprecated] now also appears on impl ClassType, which is incorrect.

So perhaps we should split out the Unavailable from Availability (and maybe rename it to PlatformCfg)? Since that part is always going to be a cfg-gate, which has interactions with higher-level cfg-gates (and must propagate to imports like generated/[Framework]/mod.rs), while introduced and deprecated will always only need to apply to the statement/method/field they're associated with.

Maybe it would even make sense to add PlatformCfg as a field of ItemIdentifier? Since these two are access so often together.

Instead of passing the (un-)availability around everywhere like this, I think it would be fine to introduce a few optional fields in Context<'_> that carried this information (since the context is already passed everywhere).

This would also be useful for other things in the future.

So something like (you can freely add only the stuff you need now, just expanding on the example to show the idea):

struct Context<'a> {
    // ... Existing fields

    /// Set whenever we know what the current library is.
    current_library: Cell<Option<Arc<Library>>>,
    /// Set when parsing methods, struct fields, enum fields, ...
    current_type: Cell<Option<(ItemIdentifier, Unavailability)>>,
}

impl Context<'_> {
    fn library(&self) -> Arc<Library> {
        self.current_library.clone().take()
    }

    fn in_library<R>(&self, library: Arc<Library>, f: impl FnOnce(&Self) -> R) -> R {
        self.current_library.set(Some(library));
        let result = f(self);
        self.current_library.set(None);
        result
    }

    // ... Similar methods for the others
}

I did part of this by adding current_unavailability to Context. In this specific case library is a &mut Library and so passing it in as even a Arc<Library> would require a clone (I think?). Library doesn't derive(Clone)and I didn't feel like adding that. It's definitely cleaner but I'm not in love with it.

This should go inside the extern_static! call, and the macro itself in icrate/src/macros.rs should instead be updated to allow it - otherwise, the cfg attribute will be improperly picked up by auto_doc_cfg (it currently works though because generated/[Framework]/mod.rs re-applies the attribute).

Same goes for typed_enum! and typed_extensible_enum!.

Actually, reflecting on this a bit more, perhaps we should instead aim to move as many cfg attributes as we can to outside macro invocations, to allow the compiler to skip evaluating the macro at all?

Actually, reflecting on this a bit more, perhaps we should instead aim to move as many cfg attributes as we can to outside macro invocations, to allow the compiler to skip evaluating the macro at all?

Yeah, I went back and forth on where to put the cfg attributes and felt that outside the macro was better. I should make sure it's consistent though.

For some unclear reason, after updating macOS, I ended up with errors on the enum macros so I put the cfg attributes on all the macros (I think). I had to use just the unavailable part as the #[deprecated] stuff before the macro causes clippy lint issues. I might try and re-add them.

I suspect this is not the only case (it's just the only one caught since we're compiling for macOS), perhaps it would make sense to change Stmt::Methods::category to Option<(ItemIdentifier<Option<String>>, Availability)>?

This is also an argument for adding Unavailable/PlatformCfg to ItemIdentifier, then the problem would neatly go away.

I don't know that this is the correct way to deal with this. I noticed the generated cfg attributes were gone for superclass functions. I'm guessing that the Availability::parse(entity, context) here checked the availability of the super not the subclass.